There are two main ways for network operators to provide granular performance guarantees: Integrated Services (IntServ) and Differentiated Services (DiffServ). Whilst IntServ has suffered from scalability challenges, DiffServ has become popular. Within the DiffServ framework, operators choose to provide various Classes of Service (CoS) such as Expedited Forwarding (EF), Assured Forwarding (AF) and Best Effort (DE) delivery, each of which corresponds to different Quality of Service (QoS) promises. For example, an operator can choose to offer within a single country 20 ms of round trip delay, 99.9% packet delivery rate and a jitter of 2 ms for a CoS like EF. Consumers, i.e. service providers that deliver data over the networks, purchase a specified throughput through the network in advance with pre-defined characteristics for which they expect pre-agreed Service Level Agreements (SLAs). Performance is monitored on the network and should performance drop below the promised targets, the network operator might have to compensate for this breach using a credit system or similar. The data packets that enter the network from the client (either a single client or a group of clients) are marked with the appropriate CoS in the traffic in the Type of Service (ToS) field or in the Differentiated Services Code Point (DSCP) field by the client themselves or an edge device managed by the operator.
The applicant's co-pending international patent application WO2014/068268 discloses a method in services are re-mapped to a different class of service based on predictive analytics on network performance for all the available classes of service. However, this proposal still adhered to the 5 major classes of services (EF, AF1, AF2, AF3, DE) for re-mapping. In the ensuing discussion the conventional EF/AFx/DE DiffServ model will be referred to as classic DiffServ to distinguish its behaviour from the adaptive QoS model of the present application.
The learning process can result in drastic changes for the network from one iteration to the next. Each time a new set of DSCP values and associated QoS models are advertised, previous sets are discontinued. This is a result of the classification mechanism using historical data from the preceding learning interval—if a CoS was determined to be unsustainable in the preceding learning interval, this CoS will not be advertised after the current learning iteration. This situation arises due to one of two reasons: the network is unable to guarantee the required QoS or the network policies have required the primary learning process to no longer use the specific QoS SLA as a cluster centre. Whilst new sessions are not disadvantaged by this method, existing services must be remapped into the new set of classes of service. Also, the learning method can be computationally intensive and therefore take a significant amount of time to re-learn cluster centres and route profiles. In the intermediate time where network data about service performance is still being collected, this network data remains unused till the next iteration of the learning algorithm, which could be, for example, every hour or every day. Service sessions themselves could last shorter time periods and/or might benefit from more frequent monitoring with respect to adherence to promised SLA when the session was admitted. Two limitations are hence identified: QoS remains unmonitored in the shorter term between iterations of route classification and the time-variance of CoS causes continuity challenges for existing services.
Such challenges arise in a more general context where time variation due to periodic learning intervals results in drastic disruptions to continuity in stateful systems as well as periods where monitoring cannot take place because the primary learning process is still consuming data from the previous interval. Learning methods that are fully ‘real-time’ are unlikely to suffer from this challenge but it might not be possible to have such a learning method due to the processing time required to consume and analyse the vast amount of data in a single iteration. Therefore, in this particular application, not only is the frequency of monitoring less than we would like in order to identify QoS breaches but statefulness can be lost due to services still marking their packets for an expired CoS over a longer session, expecting this SLA to be delivered, even after the QoS model has been discontinued.
There are two main ways for network operators to provide granular performance guarantees: Integrated Services (IntServ) and Differentiated Services (DiffServ). Whilst IntServ has suffered from scalability challenges, DiffServ has become popular. Within the DiffServ framework, operators choose to provide various Classes of Service (CoS) such as Expedited Forwarding (EF), Assured Forwarding (AF) and Best Effort (DE) delivery, each of which corresponds to different Quality of Service (QoS) promises. For example, an operator can choose to offer within a single country 20 ms of round trip delay, 99.9% packet delivery rate and a jitter of 2 ms for a CoS like EF. Consumers, i.e. service providers that deliver data over the networks, purchase a specified throughput through the network in advance with pre-defined characteristics for which they expect pre-agreed Service Level Agreements (SLAs). Performance is monitored on the network and should performance drop below the promised targets, the network operator might have to compensate for this breach using a credit system or similar. The data packets that enter the network from the client (either a single client or a group of clients) are marked with the appropriate CoS in the traffic in the Type of Service (ToS) field or in the Differentiated Services Code Point (DSCP) field by the client themselves or an edge device managed by the operator.
The applicant's co-pending international patent application WO2014/068268 discloses a method in services are re-mapped to a different class of service based on predictive analytics on network performance for all the available classes of service. However, this proposal still adhered to the 5 major classes of services (EF, AF1, AF2, AF3, DE) for re-mapping. In the ensuing discussion the conventional EF/AFx/DE DiffServ model will be referred to as classic DiffServ to distinguish its behaviour from an adaptive QoS model, such as that disclosed by WO2014/068268.